BBS in a Box 3/BBS in a box - Trilogy III.iso/Files/Tele/A/AnalyzeCL.9 Folder/AnalyzeCL Notes

Text File | 1989-05-03 | 30.4 KB | 685 lines | [TEXT/QED1]

       'Analyze CL 0.9' Users Guide/Notes


** Preface **

Inspiration for the program was provided by B.Delacey's BASIC Callerlog
Analyzer. However, this program was written from scratch and does not
borrow code from other sources.


** How to use it... **

Copy one of more 'Callerlog' files into a file called 'Callerlog Archive',
in chronological order.  If you only have one Callerlog, you can just
rename it.  (Note: I did it this way because I like to list the callerlog
when I logon, and I like to keep it short. Before I clear it, I append it
to 'Callerlog Archive'.)

Run 'AnalyzeCallers' (on the same folder as 'Callerlog Archive').

Just to see what it will do, respond with <CR> to all questions
all questions, then look at 'CL Analysis'.

** Options **

== File Name ==

Version 0.88+ allows one to pick the input file name. (Version 1.0 will
have a Mac interface.)  Unfortunately, the std. 'readln' rtn. does not
support backspace, so typing mistakes are to be avoided. A <return> will
cause AnalyzeCL to assume input in "Callerlog Archive", which should be
on the same folder as AnalyzeCL.  You may access other folders by
specifying the pathname here, though I currently allow 32 char. max.

== Start of Day Time ==

This time is used to set the hour of 'Start_Time'. This date/time
determines which day a particular login will be attributed to. I.e.,
if set to 8 (AM), a 7:30 login on Wed., 11/25 will be tallied as a
Tuesday event. This time is very important in determining Up/Down time.
The default is 4 AM which is probably good for 24 hr systems.


== Start/End Date ==

These restrict the analyzer to a subset of the total Callerlog. If <cr>
is entered, the default will be the first time/last time on the file. The
options may be set separately, i.e you can specify a start_time and use
the default end time.

Dates must be entered in 'MM/DD/YY' format, but this version is smart
enough to handle short forms such as '9/1', '10/22', '9/1/86'. (Version
0.7 required complete specification with leading zeros.) If no year
is specified, '/88' is assumed.

If a start date is explicitly entered, then a reponse of 'w' or 'W' to the
'End Date' prompt will set the end date to one week past the start date. A
number ranging from 2-9 may follow the 'w', resulting in analysis of that
number of weeks.

If a start date is explicitly entered, then a reponse of 'm' or 'M' to the
'End Date' prompt will set the end date the effective end of the month.



== ' List users as processed? ([Y]/N) : ' ==

Unless 'N' is entered, the login time and user name of each caller will
scroll on the screen as it is processed. This slows the program by a
measurable amount (0-5%), but it's reassuring to see that it's really
doing something, especially on long input files.

== ' Output condensed Callerlog? (Y/[N]) : ' ==

If 'Y' or 'y' is entered, Analyze_CL will created a file named 'Condensed
CL' containing one record for each call. This record shows the following:
    Time of call
    User name
    Elapsed time of call
    Total # of logins for this user including this one.
    Number of private messages sent for this call only.
    Number of public messages sent  for this call only.
    Number of files downloaded  for this call only.
    Number of files uploaded    for this call only.
    Number of text files read   for this call only.

== ' Long line format (>80 columns)?  ([Y]/N) : ' ==

If 'Y' or 'y' is entered, Analyze_CL will include total connect time
and last login date for each user. This necessarily extends the report
line past 80 columns, so if this information is not wanted or you want
to fit the output into narrower format, answer 'N'.

== ' Direct output to printer? (Y/[N]) : ' ==

If 'Y' or 'y' is entered, Analyze_CL will send the output directly
to the printer, rather than saving as a file. I still need to tweek this
a bit as there are a few extraneous formfeeds. If the 'Long line format'
is also selected, the printer is switched to condensed mode and 8 lines
per inch vertical spacing.

== ' Save file references separately? (Y/[N]) : ' ==

If 'Y' or 'y' is entered, Analyze_CL will create a file called 'File Ref.s'
that will contain a list of files that were referenced within the specified
interval.  Each line will contain the following data:
    Upload flag.     'U' if file was uploaded else ' '.
    Access count.    # of times the file was downloaded.
    Not found cnt.   # of times the file was 'not found'.
    Cancelled cnt.   # of times the file was cancelled, for any reason.
    Reference date.  Last date that the file was referenced.
    Name.            The actual file name.

All fields are separated with tabs. The file is sorted in ascending order
according to file name.


** What it does... **

Looking at the 'CL Analysis' file will show what the program does.  However,
a few comments are in order.  Everytime a 'Connection made' is found, the
matching baud rate counter is bumped and the time is extracted. The entire
session, up until 'Logged off', is 'logged' as occuring at this time.
I.e., if someone logs on at 6:55 and DLs 10 files, 10 ia added to the DL
entry of 6:00-6:59, even though some of this activity was after 7:00.

Events occuring before the specified 'Start of Day time' are treated as
occuring on the previous day with respect to the weekly, monthly, and
day_of_week reports. E.g.,assuimng a 4 AM start hour, a logon at 1 AM
Monday  counts as a Sunday login. A week is defined as the 7-day (604,800
seconds) period beginning at the Start_time.


All listed times are either time of day, or are given as 'HHH:MM', where
hours may exceed 24. Data collection is taken to the second, but is rounded
to the minute for display.

I attempted to collect up/downtime data. This report is based on the
assumption that if the BBS was up on a particular day, at least one
person would call it.  *Any* references to/on a day (such as a boot) will
set the flag indicating that the BBS was up on that day. In this instance
day intervals are defined as starting at the same time as the Start_time.
That is is the StartTime is 7 PM, days will run from 7 PM till 7 PM.


** Possible problems  **

The program captures all the data in memory, so huge Callerlogs
may cause premature completion.  The memory use is proportional to the
number of *different* file and user references. Multiple references to the
same file or user do not use extra memory.



** Probable Enhancements **

Mac interface.
User-specified output files.
User-selectable reports.
Ability to save internal database as a separate file. The file format will
be released so that  others may write special purpose analysis programs
without scanning and parsing Callerlogs.


Suggestions/comments are welcome!


** The program **

The program is over 2400 lines of generic TML Pascal. (About 80 hrs.)
I will release the source for $25 and a agreement to credit work that is
reused.


** Changes from Version 0.7 to 0.8 **

Version 0.8 has fixed several bugs including:

    Counting local connects.
    Handling 'Uploads' correctly, including overwrite case.
    Handling 'Download cancelled by sysop'
    Numerous internal changes to improve Start/End range handling.
    Automatic handling of different messages bases: only the highest
        referenced is listed.
    Others that I've forgotten...

This version adds the 'produce Condensed CL' option.

Logins out of chronological sequence are noted. This generally indicates
that either Callerlogs were included in the "Callerlog Archive" out of
order, or that sections of a Callerlog occur twice, which happens if you
copy a callerlog into the archive without clearing it, then copy a later
copy of the same callerlog, with some of the same records, into the archive.

Metered menus are now supported. Analyze_CL will pick up the names of
the first three menus referenced and print them in the final report
along with an ID/index #.  This number is a column header in the other
reports (where appropriate), in which the time spent in the menu is
given as a percent of total. Menus referenced after the first three are
ignored. If you don't use metered menus, the reports will not indicate
any sign of them.

The reports have been tweaked so that they will fit into 80-column output
if 2 or fewer menus are referenced.

File names of greater than 32 characters are truncated to 32.

Although it's not a new feature, this was not previously documented:

    If a file has been uploaded in the interval of the report,
    an  asterick precedes the name in the DL report.

A lot more feedback is provided during execution. Note
the blinding speed of the sorts!

As you may note, the capability to sort by name, as opposed to access
count, has been deleted. (I never used it.) The new version does maintain
the list as sorted by name, so that files/users with the same access/login
count are sorted by names. This is equivalent to doing a secondary sort
by name.  Let me know if you need sorting by name.

And, finally, I've strengthened the wording of the 'shareware' statement.
If you don't think this program is worth $4.78, then don't use it.

** Version 0.84 **

Several bugs have been fixed, and a few new features added. Frankly, I
can't remember what they all are other than the public messages column
of the weekly report has been fixed, the Condensed Callerlog output is
as documented, and the Up/Down time day range has been modified slightly.
The order of the reports is slightly different, and the Connect report
includes the percentages at different baud rates.


** Version 0.86 **

The Start_time logic is now correct, correcting several minor problems
in terms of logging 'by_day' and Up/Down time.  This change also allows
the user to make consistent weekly interval studies, i.e. the user can
control the Start_time/End_time closely enough to run a series of
connected analyses.  (This concept is extremely difficult to explain
without several detailed examples, and my revenue from AnalyzeCL is too
small to go to the effort. Play around with some very simple test files
and you'll figure it out.)

The Hourly and Day_of_Week reports have been changed to start on the
Start_Date/Hr.  That is, if the first call in the Callerlog Archive
starts on a Wednesday, the Day_Of_Week report will run from Wed. to
Tuesday.

As noted in the 'Long output format' section, Total Connect Time &
Last Login Date is shown for individual users if this option is picked.

Metered Menus:

Menus are rounded differently: 0 minutes is 30 seconds, 1 minute is
1:30, and so on. This should improve the accuracy of the reports, as
short menus may show up where they didn't before.

Also, a meter is closed automatically if the user disconnects or times
out without actuating the 'Meter turned off...' line.

*** Important New Feature in Version 0.86 ***

I started getting fed up with editing >400K Callerlog Archives, so I
added file chaining, allowing the user to switch input files in midstream.
E.g., if the file 'Callerlog Archive' has the last line :
>  "CL Oct"
  then input processing will continue with the file "CL Oct". If this file
ends with:
> "CL Nov"
  then subsequent callerlog data will taken from "CL Nov".
 Technical details (syntax): The first character must be '>' and
the file name must be enclosed in quotes. ">>>" will do as well, and
may be easier to spot.  Any data within a file past this line will be
ignored.


That's all I can remember for now, though I probably included some other
fixes/enhancements that I've forgotten.  Keep those cards and letters
coming!  (Several of these changes were user-suggested.)


*** Version 0.88 ***

The 'W' option for End_date is available and documented. See above for
details.

The 'Save file references' option exists.  A future version of FSP (File
Section Processor) will use this file to enhance its capabilities. For
example, FSP will be able to run through the RRHost file system and mark
any files that have not been referenced within 'n' days.

The bug that revealed itself as a incorrect end_date, which caused a very
long Up/Downtime report, was fixed with the assistance of John Gillett,
who provided a Callerlog Archive with which to duplicate the problem
reliably. (It's easy to fix a bug if you can force it to happen. The
intermittent ones cause the problems.)

Usage figures are now calculated on a Total, Weekly, Monthly, Hourly,
and Daily (Day_of_Week) basis.  This is a *lot* harder than it would
first appear, particularly in the Hourly and Daily cases, as these
represent separate time chunks each of which may or may not be within
the Start-End interval.  I suspect that there is a subtle bug within
the Day_of_week usage, but I'm releasing .88 anyway. If I'm right, it
shows up as a discrepancy on the last day of the interval.

Usage is based on (Connect Time * 100 ) DIV Total time. (Accurate
determination of the total is the hard part.  It is important to note
that the 'Total' connect on the Hourly report is not used. This figure
represents the total time of calls initiated within the particular hour,
which is used to calculate average call length and menu percentages. The
total used in the Usage calculations is a separate number containing the
connect time within each hour. E.g. a call from 17:30 to 19:10 will add
1800 seconds to the 17 hour slot, 3600 to the 18 hr slot, and 600 to the
19th slot.   Boundary conditions such as this are ignored for other cases,
all of which have subtantially longer intervals and fewer boundaries,
reducing the probability of problems with crossings.

In conclusion, the Usage figures will be generally correct, but subtle
sources of error remain, and the results may be inaccurate in some
cases.

As before, there may have been other changes, but that's all I can
remember right now.


*** Version 0.881 ***

Version 0.881 handles 'The .... BBS is ready for calls...' with less
restriction. Prior versions required 'The' in the first three
characters of the line, and that 'ready' be in column 20. Version 0.881
still requires the first condition (in order to detect boots within a
connect session, i.e. between 'Connection made...' and 'Logged off...'.)
but the 'ready' may be in any column as long as it's present. The
time/date at the end of the line must use the same format as Red Ryder
Host 1.01.

The new utilities 'ArchiveCL' and ZapCLArch' are specifically designed
to be used with Red Ryder Host and AnalyzeCL in order to provide accurate
boot counts regardless of Cmd#50 application invocations. See associated
documentation (for those utilities) for details.


*** Version 0.883 ***

Version 0.883 has several changes:

1)  Previous versions of AnalyzeCL required dates in the exact form that
RRHost puts them out: 'MM/DD/YY at HH:MM:SS', at the end of a line. This
version includes substantial (but not infallible) validity testing and uses
a much slower and more flexible date conversion routine if necessary, thus
accepting dates with no leading zeros (2/9/88), non-24hr time (6:18:20
PM), and various other bad formats.

The Start-Time is an exception in that AnalyzeCL requires it to be correct,
i.e. ' at ' should appear 8 characters from the end of the line for
AnalyzeCL to recognize that the line contains a time.

All non-standard times are logged as anomalies, with an indication as to why
AnalyzeCL flagged it, regardless of whether it was able to determine the
correct date/time.

(Date/time conversions are done at least twice for every call and are quite
important in terms of processing speed. This is why validity checking was
NOT done.  Development versions with simple validity checking were running
about 4 percent longer than .881 so this code was optimized even more, using
inline code for every digit of the time/date. By doing so, the performance
is roughly the same as 0.881.)

2)  Start/end time specification defaults to 1988 rather than 1986.
(AnalyzeCL has been around longer than it seems!)

3)  AnalyzeCL now tallies External Application calls.  This effort is not
finished and future versions will probably include more detailed reports,
but this version will list all external applications that are called, how
many times each is called, and the last date of reference if the following
format is used within the callerlog.

    A )   'Ext' should be in the first three columns of the line.
    B )   The application name should be enclosed within '<' and '>', as
          file names are currently handled.
    C )   If a pathname is used, all folder names will be dropped, again,
          just like file names. (This is not coincidental....)

    Example:
    External Application called : <Mystery>

If no external application calls are listed in the Callerlog, this report
will not appear in the output.

4)  AnalyzeCL now monitors memory usage and will terminate gracefully if it
starts to run out.

5)    AnalyzeCL limits the interval to a year (31557600 seconds), thus
avoiding stepping on memory outside of arrays.  This particular feature
wasn't extensively tested, so there still may be some problems for very
large time intervals, especially in usage percentages.

Another Shareware plea....

It has come to my attention that there are people using AnalyzeCL without
paying, claiming that it isn't good enough 'yet'.  While I admit that
the program is far from perfect, I claim that it provides a very useful
function AS IS, and that they wouldn't be using it at all if it wasn't
worth the something.  I challenge anyone who is using this program to try
to do any of its functions, such as making a list of users, or a list of
file DLs, by hand, and then time how long it takes.  Put some value on your
time and then decide if this program is worth the token offering that
I request.  The reason the amount is so small is that I'm certain that this
(and my other utilities) can save the RRHost Sysop that much time and effort
in ONE use, so that a reasonable person can't help but send the cash.  None
of my utilities (with the possible exception of FSP, once one gets the hang
of it) is indispensable, including this one.  A sysop doesn't really need to
have as list of DLed files, but if you find it useful enough to use it, then
you owe me a payment.

Also, it has come to my attention that AnalyzeCL is being distributed via
channels other than GEnie.  This is fine, but please keep this file with it.
I don't wish to repeat the information contained herein, and there have been
some bug reports that are explained here.

It's getting late and I have FSP work to do, so I'll call it quits.  The
next AnalyzeCL will probably have more support for external applications
and may have some sort of histogram capability.  There may be some internal
improvements to speed it up as well.


*** Version 0.89 ***

Bug fixes:

1)  The method of calculating the amount of time spent in a given day of the
week (Sun., Monday, etc) was wrong, leading to incorrect usage percentages.
This problem is fixed.  The fix improves accuracy as well, taking partial
days into account, whereas the old method (even it worked as originally
intended) assumed 86400 second days regardless of when the exact start &
end times occurred.

2) A very difficult-to-track bug that occasionally resulted in erroneous
Menu 3 percentages for Monday in the Day of Week report was fixed. (This was
actually caused by a subscript error in the hourly data collection which is
why it was so hard to find.)

3) There may have been some more, but I'm not sure.  I did double check all
the boundary conditions to make sure connect time was being charged to the
correct slots.

I was reluctant to release a new version with JUST bug fixes, so....

Improvements:

1) Metered menu validity checking is done.  If the value of a meter, when
turned off, is over 256, OR a meter is active when a user logs off, the
time is assumed to be <0>, but the problem is flagged in the anomalies
section, as well as to the screen.

2) The first 31 days of the sample are listed individually.  This is very
similar to what one would see in the 'Day of Week' report if the sample size
is one week or less, but the records are identified by date rather than by
day.  The report is limited to 31 days.

3) A 'Usage Map' report is produced.  This is a graph of Time-of-day (X) vs.
Date, with each point indicating whether the BBS is in use during that
interval.  Resolution is every 20 minutes.

Example:
   4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23  0  1  2  3
   |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
22 ::::::#:::#::##:::##::###:##:::::::#::####::#######:##:##:##:::::#::::::
23 :::::::::#:#:::::########::::::::#:##:######:###:###:######::##:::::::::
24 ::::#:::::####:##:::::::::#:::#####:#######:::########::#########:::::::
25 ::::::::#####:##::::::##:##::###:::#::######:###:#######:###

On the 22nd, there were calls between 6:00-6:20,7:20-7:40,8:20-9:00...
On the 23rd, the BBS was active between 7:20-8:40, and so on.  No one called
the BBS between 2 AM and 5:20 on any day during the sample.

A ':' means that the BBS was idle during that interval, while a '#' means
one or more people called, though it may have been a very short call. It
doesn't mean the BBS was busy for 20 minutes.

This Map is intended to be a good way to get a snapshot of BBS usage.  Let
me know how it can be improved.

Also, I considered adding another report that showed up to a week of
activity  in 3 hour increments.  Anyone interested?

I've also come up with a design that will allow limited user formatting,
which may (or may not) be in the next version.  Some sort of improved
searching may be improved as most of AnalyzeCL time is spent looking
for/comparing user & file names.


*** Version 0.891 ***

Bug fixes:

1)  The Usage Map, which only records data up to 31 days, does not print
extra (and erroneous) output for longer periods.

2) The usage figures of the 'Day-of-Week' report are now correct.*

3) The usage figures of the 'Hourly' report are now correct.*

4) I forgot to mention it on .890, but the line count is now a LongInt, so
line counts of over 32K don't go negative.

*  I was embarassed to find these problems, as they shouldn't have been
there.  By way of explanation (not to be taken as an excuse) I'll point
out that it is tricky to come up with the correct totals (the divisor of
the %) for repeating intervals across an abitrary time span. E.g., give T1
& T2 are both date/times in seconds, how much of the interval fell on a
Monday, how much fell on a Tuesday, etc..  The bigger problem is that it
is virtually impossible to analyze a real CL by hand to see what the
output should be,  and test CLs are, by definition, simpler than real
ones.

Improvements:

1) Checking for 'Logged off, with metered menus pending' created a lot of
output, as this seems to be a common occurence.  I changed the logic so
that this error shows up on the screen, for those who are interested, but
does not appear in the output file.  Values of over 256 are still logged,
but this only happens if a metered menu is active when the 'Meter' is
turned off, i.e. 'Meter turned off...' is ignored is there isn't a
'Accessed metered menu...' preceding it in the same session.

2) If a Start_Date is entered...
The user may enter 'Wn' (or 'wn') as the End-date where n = 2-9.  This
will cause the end-time to be set so that AnalyzeCL will process <n> weeks
of data. E.g., 'W2' will cause 2 * 604800 seconds to be analyzed.

The user may also enter 'M' or 'm' as the end_date, which will set the
end-date to the last day of the month (effectively).  For example, if the
start date ius set to '3/1' and 'M' is entered as the end date and the
start hour is defaulted to 4 AM, then AnalyzeCL will process all entries
between 4 AM on 3/1/88 to 4 AM on 4/1/88.  If the start date is set to,
say, 3/15 with an end date of 'M', then it will process from 3/15 to 4 AM,
4/1.

Both these options apply only if a start date is entered.



** Notes on what I didn't do and why....  **

This section addresses some suggestions that I haven't implemented.

The reason the new daily & usage map reports are restricted to 31 days is
to minimize storage requirements, and that very long periods would be
difficult to read.  In any case, it is possible to run multiple passes and
put together reports that exceed this limit.  (E.g., run AnalyzeCL on
Feb., then March, and edit the two reports together.)

It was suggested that analysis of the last 31 days would be better than
the first.  I agree, but I expect that most users can run intervals of 31
days or less so that both reports cover the last 31 days.  If AnalyzeCL
were to explicitly  record the last 31 days, it would have to record ALL
the data (requiring lots of memory) or it would have to shift data around
as it was superceded.  It is much simpler to just do the first 31 days and
require the user to analyze short periods if they want these reports.

It was suggested that ' ' would be better than ':' as the 'idle' character
in the Usage Map, but this does not take into account analyses that are
not even multiples of a day.  The use of ':' shows that that time was
analyzed but the BBS was not in use, as opposed to 'that time was not
analyzed'. (See the last line in the usage map example in '.89 Changes'.)

A number of people have suggested that AnalyzeCL might put out histograms
of usage or logins.  While I won't rule out such things completely, they
are slightly contrary to the philosophy of AnalyzeCL.  The intent is to
extract as much information as possible from the callerlog and present it
in a usable manner. Most of the reports have to be done in a
context-sensitive fashion, which means that AnalyzeCL has to look at all
of the data to come up with the right numbers.  In other words, the
primary function is data extraction, not presentation.  If AnalyzeCL were
to list all possible formats of reports, based on the collected data, the
CL Analysis file would get bigger and bigger, without actually presenting
any more information. Such customized displays can be produced by running
ACL output into other Mac applications, such as Excel or Cricketdraw, and
I will try and make this easier in the future.  I may set up a Hypercard
script that does some of this sort of thing so that anyone who wants a
special format will be able to do so without too much trouble.  The
shareware program InfoMaker can be used to produce tab-delineated files
(suitable for most spreadsheets or databases) from AnalyzeCL reports if
each report are placed in its own headerless file.  When I add the Mac
interface, more flexibility in output formats will be possible.

QUED/M, a really nice text editor with macro capability, can also be used
to customize ACL output to taste.  The same editor can also be used to
change old 'Flags; output to a format which will be logged by AnalyzeCL.
Specifically, the command
  Change ":b*External Application \(.*\) accessed." to
  "External <\1> called..."  "gat-wA"
will fix everything with a single click. ( The '\1' is replaced by whatever
was in the parentheses in the first expression, on a string-by-string basis.)




*** Version 0.9 ***  4/30/89

Bug fixes:
A bug in the monthly report (that showed up with 12 month reports)
was fixed.

A limitation in metered menu reporting was dicovered and alleviated.  The
first three metered menus that are encountered are monitored, meaning that
total time spent in each menu is estimated.  AnaluzeCL uses units of .5
minutes and a variable size of 16 bits, thus running into overflow at 546
hours.  This means that any menu total that is over 546 hours will be
incorrect.  For example, if a BBS is busy 100% of the time (744) hours,
and 74% of the time is spent in a particular menu, then that total will be
over 546 (744*.74) and will come up with an incorrect menu usage for that
month.  This result is not very likely in a single month, but can occur on
a moderately busy BBS in a yearly totals.  Why don't I change it?  The
alternative is to extend the variable size to 32 bits, so, given three
fields, adding another 6 bytes of storage per record.  This sub-record is
used extensively throughout AnalyzeCL, so the added requirements would add
up.  The problem will not occur in most cases, so I choose to leave it as
is.

The default year (for start/end date entry) was changed to
1989.  Version .891 used a 1988 default.


Some tweaking of date outputs was done so that no embedded blanks are
present.  For example, what was '2/ 1/89/ will now be '2/01/89'.

RRHost 2.0 Compatibility:
Both 9600 and 19200 baud rates are supported, so that AnalyzeCL will
report the percentage of calls coming in at those rates.

'Launching' of external applications is now recognized.  All launched
external applications are listed along with the last date they were
referenced and how many times they were launched.


Netmail Compatibility:
AnalyzeCL detects TSYNCH events and lists the number that occur
within a logging interval.  No special processing is done for either
TSYNCH or scheduled netmail events, i.e. they are ignored, but such events
will not affect the other reports.  I was doubtful that more information
would be particularly useful, and the effort would be nontrivial.  I'm
open to suggestions on the matter, but I don't guarantee support of any
RRHost add-ons that I don't use, and Tabby is one of them.


Two line system 'support':
I place 'support' in quotes for a reason.  I don't have two lines and have
no plans to add one.  This particular capability is provided 'as is', in
the hope that will be useful.  If there are bugs, I reserve the right to
drop the capability rather than fix it.  However, I'm always willing to
listen to suggestions.

Assumptions:
1)  The sysop has separate CL's for each phone line.
2)  The CL's cover the same interval of time.  (This is important.)
If one CL covers 1 day and the other covers a week, the usage percentages
will be incorrect.
3) If CL's are chained, all of the Callerlogs for the first line must be
processed prior to switching to the CLs of the second line.

Add  >2nd "<name of 2nd callerlog"  at the end of the first callerlog.
The first character of the line must be '>', the second character must be
'2', and the path of the second CL must be in double quotes.

Run AnalyzeCL in the normal fashion.  Most tables and reports will be
identical except for the usage report.  It will look something like this:

   4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23  0  1  2  3
   |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
21 ::::###::::%%%:::#####:#:%%###::#$$###:##::%%$$#:#:##:#:%$%$::######::::

where
# indicates that line #1 was used,
% indicates that line #2 was used,
$ indicated that both lines were used, and
: indicates that neither line was used within a given 20 minute interval.

No other reports are line-specific.  For example, AnalyzeCL does not keep
track of how many calls were received on each line.  However, it is simple
to run AnalyzeCL on the individual lines to get this information.